As telecommunication data transmission is increasingly reliant on packet-based networks (e.g. Ethernet, MPLS/IP), robust methods for time and frequency synchronization within these networks are more and more required. By synchronization, a way of distributing common time and frequency references to network clocks, embedded within network nodes, in order to align their time and frequency scales, is meant.
Precision Time Protocol (PTP), standardized by the IEEE (Institut of Electrical and Electronics Engineers), is one of the most up-to-date standard that addresses synchronization problem within packet-based networks. In fact, PTP was designed as an improvement on current time synchronization technologies such as Network Time Protocol (NTP).
PTP is a packet-based protocol relying on the measurement of the communication path delay between a time source, designated as a master clock, and a receiver, designated as a slave clock.
PTP has first introduced Boundary Clock (BC) concept, but very soon with the development of packet-based networks, a plurality of BC limitations have been pointed out, especially with regards to the possible number of cascaded BCs in a synchronization chain. Indeed, it is shown that the synchronization transfer over a long chain of BCs can result in a large phase error accumulation. Such error is mainly due to                PTP message exchanges between different pairs of successive BCs in the chain which may not necessarily be syntonized (synchronized in frequency); as well as,        gain peaking and noise generation in phase-locked loop servos at the successive BCs.        
Thus, as an alternative to BC, a recent concept, called Transparent Clock (TC) was specified in a second release (PTPV2) mainly with the goal of bypassing cascade scalability issue.
In principle, a TC simply provides corrections for the PTP packet residence time across the network node (i.e. a bridge, a router, a switch, a repeater, or the like). The residence time corresponds here to the time needed by a PTP event message to propagate from an ingress port to an egress port of the network node. To that end, TC proceeds with:                PTP event messages (Sync, Delay_req, Delay_Res for example) identification;        their residence time computing (Both ingress and egress timestamps are recorded and saved to calculate the residence time);        updating a newly introduced time-interval field within PTP event messages (named CF for Correction Field); and subsequently        forwarding, just as an ordinary switch, these modified PTP event messages.        
Accordingly, one can retain that TC forwards PTP event message but after modifying it, though keeping in mind what CF modification may induce.
Hence, as soon as tunneling and encapsulation are evoked, several problems with regard to PTP event messages modification arise. In fact, the ability to modify a PTP packet (or more generally, a PTP event message) encapsulated within a tunnel raises several concerns and issues. Among those problems, one can mention:                the modification of encapsulated PTP event messages raises the concern of layer violation as it contradicts the principle of encapsulation itself which aims to protect encapsulated data from being modified by intermediate nodes of the tunnel. The document “Issues with the Transparent Clock concept of PTPv2”, France Telecom, ITU-T SG15/Q13 interim meeting, 16 Mar.-20 Mar. 2009, San Jose reveals such a problem. Regarding this matter, a given network node is allowed to modify a packet payload only if its address is the destination address of the packet. Otherwise, the node violates the layer separation principle;        the modification itself may be impossible: any modification of the PTP packet content requires the creation of a new packet with all the initial encapsulation headers and recomputed checksums. However, intermediate nodes of a tunnel often do not comprise all the protocol stacks implemented for this purpose. For example, SDH equipments in the middle of an Ethernet-over-SDH (EoS) tunnel are not likely to have an Ethernet protocol stack implemented in order to regenerate the Ethernet header and especially to recompute the Ethernet Frame Check Sequence (FCS) (e.g. in a Frame-mapped Generic Framing Procedure (GFP) as defined by the ITU-T G.7041). Indeed, the modification of the correction field within the encapsulated PTP message requires the recomputation of all FCSs (e.g. both Ethernet FCS and GFP FCS in an EoS encapsulation context) in order to avoid the whole encapsulating frame from being discarded at reception;        in the case of IPSec tunneling or, more generally, of encryption use, the modification of the encapsulated PTP packet content, by intermediate nodes, simply reveals as an impossible task (as the encryption key is not distributed to intermediate nodes for security reasons).        
It is one object of the present invention to overcome at least one of the aforementioned problems and to offer advantages over the prior art.
Another object of the present invention is to overcome at least one of the aforementioned problems without adding relatively complex circuitries to conventional TCs.
Another object of the present invention is to avoid layer violation while timing messages are handled by TCs.
Another object of the present invention is to allow TC deployment within encapsulation/tunneling embodiments, or more generally wherever it is impossible to modify timing messages.
Another object of the present invention is to permit TC deployment on an intermediate node within a tunnel, whatever its ability to access to PTP event message content.
Another object of the present invention is to permit TC deployment across encrypted tunnels within PTP networks.
Another object of the present invention is to provide a method for TC deployment across IPSec tunnels.
It is to be noted that numeral references do not connote, here, any particular order or hierarchy, and are used only for referencing purpose.